Repository navigation
Conversation
…ons` to `addGTDataVersion`
…20.b** and certainly no longer required by anything
# Conflicts: # src/main/java/com/gregtechceu/gtceu/common/CommonEventListener.java
|
Also, could you figure out the remainder of the datafixers that you didn't port yet. |
|
Also, will loading from a save without a defined data version run all the datafixers from the start? |
Sure |
Yes, but it shouldn't matter as long as they're made to not interfere with already correct data. |
…1c76b] and make it happy with the version number
|
can you move the turbine rotor item changes to a separate pr? |
sure, but I'll need this PR to be merged ASAP in that case. |
# Conflicts: # src/generated/resources/assets/gtceu/lang/en_ud.json # src/generated/resources/assets/gtceu/lang/en_us.json # src/main/java/com/gregtechceu/gtceu/common/CommonEventListener.java # src/main/java/com/gregtechceu/gtceu/integration/recipeviewer/emi/GTEMIPlugin.java
This reverts commit 70c6226
Make/Use a Stack PR if the changes are relevant/reference eachother |
|
You cannot create stacked PRs from forks. |
What
Add DFU-based data fixers as a replacement to manual legacy data conversion
Implementation Details
The implementation primarily lives in
GTDataFixersand thegtceu.common.datafixerpackage, though some utilities are also ingtceu.api.datafixer.CommonEventListener.remapIdswas removed in favor of handling the same logic with data fixers, as wasTagCompatibilityFixer.fixMachineAutoOutputTag.AI Usage
Outcome
Though initial setup may be more annoying, this PR provides considerably more stable legacy data conversion for the future.
How Was This Tested
I manually created a player inventory (carefully_crafted_inventory-dev-380df991-f603-344c-a090-369bad2a924a.zip) with since-renamed items in it and loaded it in a world to see how well upgrading works.
I also did
/test runalla bunch to test upgrading blocks and block entities, as most of the structures have out-of-date data.Additional Information
The GT data version field should be bumped with EVERY save data change, no matter how minor. Same goes for adding fixers. All machines should be registered into new schemas. Do NOT put all of them into
V0.Register new datafixers in
GTDataFixers#addFixers. Remember to bumpGTCEu.GT_DATA_VERSIONin every PR that changes existing save data and add a schema & fixer for it here.For changes that do not change named types or add new (block) entities, use
SAME_NAMESPACEDfor the schema. Register machines (and other block entities) in a schema overridingSchema#registerBlockEntities.Reference vanilla schemas for more information on that, examples named below. Also check how they're used in vanilla's
DataFixersclass.net.minecraft.util.datafix.schemas.V1460,net.minecraft.util.datafix.schemas.V1906Note how only fields that use other registered types (such as item/fluid stacks) are defined. The same should be done for all types.
Potential Compatibility Issues
The auto output trait fix might? be wrong, not sure. I couldn't really test it because I managed to corrupt my freshest testing world before I figured out how to fix the forge registry ID map.